Method and system for user initiated inter-device, inter-system, and inter-internet protocol address handoff

ABSTRACT

Apparatus and method by which Internet Protocol (IP) traffic can be transferred (i.e. handoff) between two different terminals operating according to two different technology standards in two different systems with two different IP addresses. For example, a session handoff can be made between a terminal in Wireless Local Area Network (WLAN) a terminal in a 3GPP UMTS or between a terminal in CDMA2000 and a terminal in a 3GPP UMTS. These terminals can be either physically separate entities or logical entities that are encapsulated within a common enclosure.

CROSS REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority from U.S. provisionalapplication No. 60/408,475 and filed Sep. 3, 2002, which is incorporatedby reference as if fully set forth.

BACKGROUND

[0002] Internet Protocol (IP) traffic can typically be transferred (i.e.handoff) when dealing with a single terminal operating with the samesystem and employing the same IP address. Some systems can accommodate asingle terminal operating between systems and wherein the IP addressesmay be different. However, there are no systems which provide thecapability of transferring an existing session between two terminals, inwhich two systems and two different IP addresses are involved.

SUMMARY

[0003] A transfer (i.e. handoff) of internet protocol (IP) trafficbetween two different terminals operating under two different technologystandards and in two different systems with two different IP addressesmay be either subscriber initiated voluntarily or subscriber-initiatedresponsive to network solicitation, wherein the handoff process iseffected employing optimizing routing mobile IP-(MIP).

BRIEF DESCRIPTION OF THE DRAWING(S)

[0004] The present invention will be understood from a consideration ofthe accompanying description and drawings wherein like elements aredesignated by like numerals and wherein:

[0005]FIG. 1 is a system diagram of the interworking approved Scenario2;

[0006]FIG. 2 is a system diagram of the interworking approach toScenario 3;

[0007]FIG. 3 is a system diagram illustrating how to achieve Handoffwith this configuration without any changes to WLAN;

[0008]FIG. 4 is a block listing of Handoff Triggers;

[0009]FIG. 5 is a method flow illustrating general handover scenario(with target HLR/HSS access);

[0010]FIG. 6 is a method flow illustrating general handover scenario(with target HLR/HSS access);

[0011]FIG. 7 is a method flow illustrating handover from WLAN to UMTS;

[0012]FIG. 8 is a method flow illustrating handover scenario from UMTSto WLAN (with Interworking); and

[0013]FIG. 9 is a method flow illustrating handover scenario from UMTSto WLAN (without Interworking).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

[0014] The present invention discloses apparatus and method whereinInternet Protocol (IP) traffic can be transferred (i.e., handoff)between two different terminals operating according to two differenttechnology standards in two different systems with two different IPaddresses. For example, session handoff between a Wireless Local AreaNetwork (WLAN) terminal and 3GPP UMTS terminal or between CDMA2000terminal and 3GPP UMTS terminal. The invention may be utilized byterminals which can be either physically separate entities or separatelogical entities that are encapsulated in a common enclosure.

[0015] The invention is based on the user (service subscriber)initiating handoff procedures between the two terminals. The subscribermay initiate the handoff process based on network solicitation (e.g.,the network advises the user that WLAN coverage is available in thisgeographic vicinity) or based on unsolicited action by the subscriber(e.g., the subscriber is performing a transaction over WLAN and decidesthat he needs to leave the WLAN and continue the same transaction on hisUMTS terminal).

[0016] There are several mechanisms by which the user initiates anapplication based handoff. For example, the software session (or theterminal itself) may include a button that triggers initiation ofsession handoff procedures. The session handoff trigger may also requestthe target system/terminal/IP address to which the session will betransferred. The request may be part of a stored program in thesubscriber's terminal or alternatively be sent directly to thesubscriber asking for the target IP address, terminal phone number, orterminal identification number. In a second approach, the source systemqueries the subscriber profile at the Home Location Registry/-HomeSubscriber Service (HLR/HSS) to obtain the target address for handoff.If the subscriber has more than one terminal, the source system mayrequest the subscriber to choose the desired target terminal. In a casewhere the desired terminal is switched off, the source system may askthe subscriber to switch the terminal ON and activate its IP connection(i.e., obtain the IP address or activate the packet data protocol (PDP)context) before proceeding with the handoff. In a case where the secondterminal (e.g., UMTS) is attached and no IP address is allocated (i.e.,inactive PDP context), the source system may trigger the target systemto perform network initiated PDP context activation procedures.

[0017] When the target system, target terminal, and target IP addresshave been identified, the handoff process can be finalized usingoptimized routing mobile IP version 4 (MIPv4) to direct the sessiontraffic directly to the target triplet (system, IP address, terminal).Once the traffic is rerouted to the new destination, the source systemcan advise the subscriber that the handoff is completed and that thesubscriber can terminate this connection, and switch off the currentterminal after which all resources can be released.

[0018] Setting forth the present invention in greater detail, and withreference to the drawings, FIG. 1 represents the present state of theart wherein a personal computer (PC) 10 having a WLAN card 12 is capableof communicating with an access point (AP) 20 of a WLAN 19. The WLAN 19has only limited access to the 3^(rd) generation partnership project(3GPP) system. The PC 10 communicates with an internet protocol (IP)network 24 to send and receive messages. However, PC 10 has access tothe 3GPP system 25 only for authentication and billing through the AAAfunction 22 of the WLAN AP 20, the AAA function 26 of UTRAN 25 and theHSS 28. There is no capability of a handoff as between PC 10 and awireless user equipment (UE) 15. The capability shown in FIG. 1 showsinter-working in accordance with approved Scenario 2. Although FIG. 1shows the PC 10 and a user equipment 15 as separate entities, it shouldbe understood that they may be logical entities contained with a commonhousing (not shown).

[0019]FIG. 2 shows an interworking employing a new approach to Scenario3, which differs from the arrangement shown in FIG. 2 with the additionof instant messaging system IMS 34. Scenario 3 provides access to packetswitching (PS) service via the serving GSN (SGSN) forming part of GSN 30in 3GPP system 25 in scenario 3. PC 10, in addition to having access toHSS 28 for authentication and billing, is further capable of obtaininginstant message system (IMS) services through IP network 24, utilizingIMS 34. Nevertheless, there is no handoff capability between PC 10 andUE 15.

[0020]FIG. 3 shows an arrangement in which a handoff is achieved withoutany changes in the WLAN 20. PC 10 is shown conducting a data sessionbetween WLAN 20 and supporting service center (SC) 36 through IP network24. The data session connection is transferred to UE 15 operatingwirelessly over the UMTS network of the 3 GPP system 25 over tower 32.

[0021]FIG. 4 is a flow diagram showing available handoff procedures.

[0022] A handoff procedure is triggered (see step S1) and may either beuser-initiated or performance-initiated. Given a user-initiated handoff(S2) the initiation may be solicited by the network (branching to S3)wherein the network informs the user that the network, for example, aWLAN, is available. In the case of an unsolicited handoff trigger, theuser may initiate the handoff (HO) on his own. In either the solicited(S3) or unsolicited (S4) handoff trigger, the handoff is immediate.

[0023] An HO may be performance-initiated (branching from S1 to S5)wherein initiation may be based upon a power measurement (branching toS6). However, WLANs do not presently support a performance-initiated HObased on power measurement.

[0024] An HO may be initiated based on frame error rate (FER) branchingfrom S5 to S7. However, a physical layer FER (PHY FER) is not supportedby a WLAN. A medium access control FER (MAC FER) may not be supported bya WLAN and results in a slow procedure.

[0025] An internet protocol FER (IP FER) results in a very slow handoffand it should further be noted that the internet protocol (IP) does nothave cyclic redundancy check (CRC).

[0026]FIG. 5 is a flow diagram showing a generalized HO scenarioemploying target home location register/home subscriber server (HLR/HSS)access. At step S11 an HO is initiated when a subscriber, which may, forexample, be a PC equipped with a WLAN card, decides to transfer acurrent session from one system, A, which may, for example, be a WLAN,to a second system, B, which may, for example, be a universal mobiletelecommunications system (UMTS). Upon making this decision, thesubscriber operates a handoff button B provided as part of thesubscriber unit, such as PC 10 shown in FIG. 3. Responsive to operationof the HO button, the subscriber is presented with a list of optiontarget systems such as, for example, WLAN, CDMA 2000, UMTS, etc. (S13).

[0027] The routine advances to S14 at which time a determination is madeas to whether there are any connections between terminals, such as PC 10and UE 15 shown in FIG. 3. If there is a connection, the routinebranches to S15 to initiate a confirmation process ensuring theconnectivity of the other terminal, for example a UMTS.

[0028] In the event that there is no connection between terminals, theroutine branches from S14 to S16 which asks the subscriber to confirmthat the other terminal, for example, the terminal in the UMTS system ison and is connected with system B. The routine then advances to S17 toinquire if system A, such as for example a WLAN, has any informationregarding the target triplet which includes the ID of system B, the IDof the terminal communicating with system B and the IP address. In theevent that system A does not have the target triplet information, thesubscriber is requested to provide the target information.

[0029] In the case where system A has the target information, theroutine branches to S19 to retrieve the necessary information about theconnections to the target system, i.e. system B. As is described above,the retrieved information is obtained either from system A or from thesubscriber. The routine then advances to S20 wherein the target systemdata base, for example, the HLR/HSS, is contacted for informationretrieval, verification and authorization. When the necessary criteriais present, the routine branches to S21 wherein system A initializes theservice at the target system B and informs the service provider, i.e.,the session partner to reroute the session traffic to system B. In theevent the current session is the only running session in system A, aninquiry may be made to the subscriber to determine if the subscriberwould like to terminate the connection to the system A or to continueoperation.

[0030]FIG. 6 shows a generalized HO scenario in which a target HLR/HSSis omitted. For purposes of simplicity, only those steps which are notshown in FIG. 5 will be described in detail.

[0031] Steps S11 through S17 are substantially identical to thecorresponding steps S11 through S17 shown in FIG. 5. However, at stepS17, in the event that system A does not have the target tripletinformation, the routine branches to step S22 to obtain the target IPaddress information from the subscriber.

[0032] Advancing from step S15, the necessary information regardingconnections to the target system are retrieved at S19, the targetinformation either being obtained from system A (S17) or from the targetaddress information provided by the subscriber (S22). The routine thenbranches to S23 wherein the target system may be contacted forinformation retrieval, verification and authorization. Thereafter if theappropriate criteria are met, the routine advances to step S21 which issubstantially the same as corresponding step S21 in FIG. 5.

[0033]FIG. 7 shows an HO scenario from a WLAN to a UMTS. Steps S11 andS12 are substantially identical to the corresponding initial steps S11and S12 of FIGS. 5 and 6. Upon operation of the HO initiation button,the routine advances to step S27, providing a window to the subscriberinviting the subscriber to select the target system from among thechoices displayed and to further ensure that the terminal intended tocommunicate with the target system is on and connected. The routine thenadvances to step S28 which is substantially identical to step S17 shownin the routines of FIGS. 5 and 6 wherein an inquiry is made as towhether the WLAN has information regarding the target triplet. In theevent that the UMTS does not have target triplet information, theroutine branches to step S29 in order to obtain the system and/orterminal information from the subscriber. Returning to step S28, theroutine loops here until the requested information is obtained. Althoughnot shown, the routine may be exited in the event that the requestedinformation is not obtained after a given number of tries, for example,three (3) tries. However, a lesser or greater number of tries may beprogrammed before aborting.

[0034] When the triplet information is obtained, the routine branches tostep S30 whereupon the HLR/HSS of the target system is contacted. Theroutine advances to step S31 to determine if the terminal is on. In theevent that the terminal is on, the routine branches to step S33 todetermine if the packet data protocol (PDP) is active. In the event thatthe PDP is not active, the routine branches to step S34 to activate thePDP context and thereafter obtain the IP address (S35), followed byperforming the rerouting process (S36).

[0035] Returning to S33, in the event that the PDP is active, the IPaddress is obtained (S35) and the rerouting process is performed (S36).

[0036] Returning to S31, if the terminal is not on, the routine branchesto S32 requesting the subscriber to switch on and confirm. The routineadvances to S37 to determine if the confirmation has been received. Ifthe confirmation has been received, the routine branches to S39 whereina predetermined delay is provided before the target system is contacted(S30).

[0037] In the event that a confirmation is not received, the routinebranches to S38 and the HO is aborted.

[0038]FIG. 8 shows an HO scenario from a UMTS to a WLAN which utilizesinterworking.

[0039] The HO routine is initiated when the subscriber makes a decisionto transfer a current session from UMTS from WLAN (S40) and thereaftertriggers the HO procedure button during the current UMTS session (S41),whereupon the subscriber is invited to select the target system from adisplay provided to the subscriber and is further alerted to assure thatthe terminal to be connected to the WLAN, for example, a PC with a WLANcard, is on and connected to the WLAN.

[0040] Thereafter, an inquiry is made as to whether the UMTS has thetarget triplet information. In the event that the UMTS does not have thetarget information, the routine branches to S44 to obtain the systemterminal and/or IP information from the subscriber, looping back to S43.When the target information is available, the routine branches to S45whereupon the HSS in the UMTS is contacted. The routine then advances toS46 to determine if the WLAN terminal is on. In the event the WLANterminal is off, the routine branches to S47 requesting the subscriberto activate the WLAN terminal and confirm activation. It should be notedthat step S47 is substantially identical to corresponding step S32 shownin FIG. 7 and the identity of these steps is shown by placing “(S32)”adjacent to step S47. Steps S48 through S50 operate in substantially thesame manner as steps S37 through S39 of FIG. 7 and are shown with theassociated equivalent step number of FIG. 7 in parenthesis. Reference toperformance to steps S48 to S50 should therefore be made to thedescription of steps S37 through S39 set forth above.

[0041] Making reference to step S50, the HSS in the UMTS is contactedafter a predetermined interval (S45) responsive to completion of stepS50.

[0042] When the WLAN terminal is identified as being on (S46) the targetIP address is obtained (S51) and the rerouting process is performed(S52).

[0043]FIG. 9 shows the scenario for HO from UMTS to WLAN withoutinterworking. Making reference to FIG. 9, steps S40 through S43 aresubstantially identical to corresponding steps S40 through S43 shown inFIG. 8 and reference should be made to the description of thesecorresponding steps as set forth above.

[0044] In the event that the UMTS does not have the target information,the program branches to step S44 which is substantially similar tocorresponding step 44 in FIG. 8 and the description thereof is set forthabove.

[0045] Once the target information is obtained, the routine branches toS53 to extract the target IP address. The existence of the IP address ischecked at step S54. If the confirmation is positive (S55), thererouting process is performed (S56). In the event that confirmation hasnot been received, the routine branches to S57 to instruct thesubscriber to turn the terminal on and provide information that thesesteps have been performed. At step S58, once the confirmation isreceived, the routine then branches to S59 and the routine returns toS43. Steps S43 through S55 are again repeated and in the event thatconfirmation is not received (S55), and this is the second inquiry, theroutine branches at S57 A whereupon the HO effort is aborted (S60).

What is claimed is:
 1. A method for providing a handoff (HO) betweenfirst and second wireless terminals respectively configured forcommunication with first and second systems, said first terminal beingdifferent from said second terminal, said first system having atechnology standard different from said second system, and respectivelyidentified by different internet protocol (IP) addresses, comprising: a)said first terminal initiating a request for an HO to said secondterminal during a current session with said first system; b) alertingthe first terminal to ensure that the second terminal is on and isconnected to the second system; c) inquiring if the first system has theconnection information; d) obtaining the IP address of the secondterminal from said connection information; and e) initiating a reroutingprocess of said current session from said first terminal to said secondterminal responsive to receipt of a confirmation of the second terminalIP address.
 2. The method of claim 1 wherein step of obtaining the IPaddress of the second terminal further comprises: checking existence ofsaid IP address.
 3. The method of claim 1 wherein the step of obtainingthe connection information further comprises: obtaining the connectioninformation from the subscriber in the event that the first system doesnot have the connection information.
 4. The method of claim 1 whereinthe step of requesting connection information comprises: obtaining thesystem ID, terminal ID and IP address for use with the second system. 5.The method of claim 1 wherein the first and second terminals areseparate independent entities.
 6. The method of claim 5 wherein thefirst and second terminals are logical entities housed within a commonenclosure.
 7. A method for providing a handoff (HO) between first andsecond wireless terminals respectively configured for communication withfirst and second systems, said first terminal being different from saidsecond terminal, said first system having a technology standarddifferent from said second system, and respectively identified bydifferent internet protocol (IP) addresses, comprising: a) said firstterminal initiating a request for an HO to said second terminal during acurrent session with said first system; b) alerting the first terminalto ensure that the second terminal is on and is connected to the secondsystem; c) inquiring if the first system has the connection information;d) obtaining the IP address of the second terminal from said connectioninformation; e) confirm receipt of the IP address of the secondterminal; f) instructing the second terminal to switch on and confirm ifthe confirmation of step (e) is not received; and g) repeating steps (a)through (e) responsive to receipt of the confirmation requested in step(f), and h) said first terminal to said second terminal responsive toreceipt of a confirmation of the second terminal IP address.
 8. Themethod of claim 7 further comprising aborting the HO procedure if theconfirmation requested in step (f) is not received.
 9. The method ofclaim 8 further comprising aborting the HO process during if aconfirmation is not received during the repeated performance of step(e).
 10. A method for providing a handoff (HO) between first and secondwireless terminals respectively configured for communication with firstand second systems, said first terminal being different from said secondterminal, said first system having a technology standard different fromsaid second system, and respectively identified by different internetprotocol (IP) addresses, comprising: a) said first terminal initiating arequest for an HO to said second terminal during a current session withsaid first system; b) alerting the first terminal to ensure that thesecond terminal is on and is connected to the second system; c)inquiring if the first system has the connection information; d)contacting a home subscriber server (HSS) in said first system; e)obtaining the internet protocol (IP) address of the second terminalresponsive to confirmation that the second terminal is on; and f)performing the rerouting process.
 11. The method of claim 10 wherein thestep of obtaining the connection information further comprises:obtaining the connection information from the subscriber in the eventthat the first system does not have the connection information.
 12. Themethod of claim 10 wherein the step of requesting connection informationcomprises: obtaining the system ID, terminal ID and IP address for usewith the second system.
 13. The method of claim 11 wherein the first andsecond terminals are separate independent entities.
 14. The method ofclaim 12 wherein the first and second terminals are logical entitieshoused within a common enclosure.
 15. A method for providing a handoff(HO) between first and second wireless terminals respectively configuredfor communication with first and second systems, said first terminalbeing different from said second terminal, said first system having atechnology standard different from said second system, and respectivelyidentified by different internet protocol (IP) addresses, comprising: a)said first terminal initiating a request for an HO to said secondterminal during a current session with said first system; b) alertingthe first terminal to ensure that the second terminal is on and isconnected to the second system; c) inquiring if the first system has theconnection information; d) contacting a home subscriber server (HSS) insaid first system; e) obtaining the internet protocol (IP) address ofthe second terminal responsive to confirmation that the second terminalis on; and f) instructing the second terminal to switch on and confirmif the confirmation of step (e) is not received; and g) repeating steps(a) through (e) responsive to receipt of the confirmation requested instep (f), and h) said first terminal to said second terminal responsiveto receipt of a confirmation of the second terminal IP address.
 16. Themethod of claim 15 further comprising aborting the HO procedure if theconfirmation requested in step (f) is not received.
 17. The method ofclaim 15 further comprising aborting the HO process during if aconfirmation is not received during the repeated performance of step(e).